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R ecent discoveries made while building a system that 
worked as a server instead of as atypical GUI applica¬ 
tion have led me to write this article. During the test¬ 
ing phase, I was surprised to see that the image grew from 
a starting size of about 8 MB to roughly 18 MB before it 
stopped requesting memory from the operating system. 
This behavior lead to the questions: Why does itgrow?Why 
does it stop growing? A manual garbage collection usually 
returned the response that 8 MB of memory had been 
freed. Most puzzling. Although the 
image didn’t grow continuously, I 
thought I had understood how it 
used memory, and now was forced 
to take a closer look at the problem. 

This article is the first of a series 
explaining how Garbage Collection 
(GC) is done in VisualWorks 

My starting point was extensive 
reading of the ParcPIace-Digitalk 
manuals and examination of the image. I ran across the 
MemoryPolicy class comment, which states: "Atypical mem¬ 
ory policy might be to run the Incremental Garbage 
Collector (IGC) in the idle loop, in low-space conditions, 
and periodically in order to keep up with the OldSpace 
death rate.” Light bulbs! My application does not fit the 
regular pattern of GUI applications! Idle times are a rarer 
event for server applications, since they do not enjoy 
human interface pauses. Instead, they might service many 
users, and always have a high-activity level. Armed with 
my apparent lack of memory-management knowledge, I 
embarked on a journey to discover exactly how Smalltalk 
deals with memory beyond the Scavenge. 


detailed introduction into GC theories. More information 
can be found on the Web at ftp://ftp.netcom.com/ 
pub/hb/hbaker/home.html, which contains access to a 
number of papers on GC theories. Hewitt and Lieberman’s 
paper "Lifetimes of Objects,” 1 and David Ungar's classic 
paper "High Performance Smalltalk Systems," 2 also lay 
groundwork for the GC logic used by current commercial 
Smalltalk systems. These papers point to a key discovery: 
namely, that most objects are short lived. In fact, 80 to 98 
percent of objects die shortly after 
bi rth. The survi vors general Iy I i ve for 
a longtime. 

With this observation in mind, a 
typical Smalltalk system divides 
memory into two areas: NewSpace 
for object creation and OldSpace for 
long-lived objects. The objective of 
a memory-management system is 
to aggressively do GC work on a 
small area of memory. Thisactivity can bedonewithinthe 
pause time between keyboard keystrokes, so the impact 
on the user isn't noticed. From time to time, checking all 
objectsin amultimegabyteimageforsurvivorsisdone, by 
using an incremental GC that runs when the system isn't 
doing more important work. Running short on memory 
will trigger more drastic measures to find and remove 
dead objects, before declaring a critical memory shortage. 
An application that doesn’t match well with the expected 
behavior will suffer from pauses, and possibly use exces¬ 
sive swap space as the OldSpace GC logic attempts to fix a 
problem that might be solvable withi n the domai n of the 
NewSpace GC logic. 


Theobj ecti ve of a memory- 
management system is to 
aggressi vely do GC work on 
a small area of memory 


GARBAGE COLLECTION 

To understand how the MemoryPolicy class interacts with 
the image, one first needs to step back and understand 
how garbage col lection works Some background informa¬ 
tion can be found in Kent Beck's "Garbage Collection 
Revealed," The Smalltalk Report, Vol. 4, No. 5, Feb. 1995, 
which talks about VisualSmalltalk, and gives the reader a 


NEWSPACE GC LOGIC 

NewSpace is really three areas, with a tenuring extension 3 
to make four. These areas are used as a base for the 
garbage-collection algorithm. 'Eden' is where objects are 
first allocated, or born. The next two areas are Survivor 
spaces. One contains live objects, while the other is empty, 
being used during an event called "The Scavenge." A 
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fourth space, 'LargeSpace', is used to handle large objects 
as a modification to the original algorithm, and attempts 
to reduce the movement of large byte objects between 
Survivor spaces. Strings that exceed roughly IK are created 
in LargeSpace with a link to Eden. 

In a small VW 2.5 Windows NT image, the sizes of the 
various spaces are: 


Eden 

204,800 bytes 

Survivor Space A 

40,960 bytes 

Survivor Space B 

40,960 bytes 

Large Space 

204,800 bytes 


THE SCAVENGE 

When Eden fills to the Eden byte-used threshold, the 
VirtualMachine (VM) invokes an event called a scavenge. 
The verb "to scavenge" is aptly defined in the Webster's 
Nsn Collegiate Dictionary's-, "to remove (as di rt or refuse) 
from an area, or to salvage from discarded or refuse mate¬ 
rial." During a scavenge, theVM locates all objectsin Eden 
and the active SurvivorSpace reachable by the systems 
roots, and copies them into the empty SurvivorSpace. 
Once the scavenge examines Eden and theoriginal active 
SurvivorSpace, those spaces now only contain dead 
objects, and are deemed empty. Memory allocation starts 
again, with objects being placed into Eden. 

As you can see, survivor objects are shuffled between 
the two SurvivorSpaces on each scavenge, with new 
objects being added from Eden. Objects that die in 


SurvivorSpace are not copied during the scavenge, and 
overall growth is based on how good or bad your applica¬ 
tion is in creating and holding new objects. You will notice 
that 40K or so of memory isn’t very big, so once the num¬ 
ber of bytes in SurvivorSpace reaches the defined thres¬ 
hold, the scavenger will tenure objects from 
SurvivorSpace to OldSpace until there is room in the 
SurvivorSpace. 

OLDSPACE 

OldSpace is many memory segments that combine to 
form a virtual chunk of contiguous memory. This leads to 
the external behavior shown to the hosti ng operati ng sys¬ 
tem. AVW image will grow by chunks; once the memory 
is allocated from the hosting operating system, it is not 
returned. Images never shrink, theyjust grow. Great, but 
with all that activity hidden in theVM, can NewSpace 
garbage collection be controlled? Certainly. In fact, you 
need to control garbage collection to solve a problem 
known as the 'Early Tenuring Issue'—the result of an 
application holding objects for a few hundred millisec¬ 
onds too long. 

When this happens, objects are tenured into OldSpace 
too early and promptly die, thus defeating the generation 
scavenging logic. This shifts NewSpace GC work to the 
OldSpace GC logic. To show how this happens, let us create 
an object that will artificially hold items and cause the early 
tenuring problem. We will then alter the size of 
SurvivorSpace to observe how it will affect performance. 
Source code will follow this article. To alter the size of 
NewSpace, you must useObjectMemory class»sizesAtStartUp: 



SurvivorSpace size times default size 


Figure 1. This figure shows restricted image growth, and allocation-rate improvements against default NewSpace size of 40K. 
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SurvivorSpace size times default size 


Figure 2.This figure depicts unrestricted memory growth. 


and ObjectMemory dass»thresholds: to change the default 
sizes and thresholds, which were chosen by ParcPIaceThe 
sizesAtStartUp: method allows me to alter the amount of 
memory VW allocations for each memory area at startup. 
The thresholds: method dictates the thresholds for Eden, 
Survivor, and LargeSpace. 

Two conditions were tested. Since memory is not free, 

I limited the amount of memory that the image could 
allocate for one of the tests. The other had full freedom to 
extend the image. For both tests, I altered the size of 
NewSpace from two times the default size up to eight 

01 dSpace is many memory 
segments that combine to form 
a virtual chunk of 
con ti guous memory 

times the default size. These changes allowed us to 
observe the effects of a survivor space that varied from 
80K to 320K. 

The EarlyTenureTest object allocates an Array of 500 ele¬ 
ments. For a certain number of seconds, a loop is per¬ 
formed, where a new String object of a given size is allocat¬ 
ed and placed in the Array, starting at element one. The 
index is incremented, and a new string is allocated into the 
next element. When the last element of the Array is 
reached, it starts agai n at element one. If the SurvivorSpace 
isn’t large enough to contain the full working set of the 


Array and it's components, some of these strings will be 
tenured intoOldSpace. 

To show how the image behaves under different condi¬ 
tions, and how OldSpaceGC really impacts performance, 
we first restrict the image’s size to 8M B. 

In Figure 1, we see allocation-rate improvements 
against the default NewSpace size of 40K. EarlyTenureTest 
instances are created usingastringsizeof 128,256,and 512 
bytes. These instances require a working set size of at least 
64K, then 128K, and finally 256K bytes. On reviewing Figure 
1, it is clear that the 128-byte allocation rate improves by 
about 80%, when we go to a Survivor size of 2x (see point 
A). For the 256-byte instance, the SurvivorSpace needs to 
goto 4x before the allocation peak (see pointB). Finally,for 
the 512-byte instance, we peak at a SurvivorSpace size of 
7x, with an improvement of almost 200% to the allocation 
rate (see point C). The impressive improvement for the 
512-byte instance happens when we avoid expensive 
OldSpace GC work. In all three cases, there is a net 
improvement in the overall work done by the application. 
Figure 2 shows what happens if memory growth is not 
restricted. 

Although the increase in memory-allocation rates is 
not as impressive as in our first case, image growth is 
affected. Using the default size, the image grows from 
8MB to 13MB. Changing the size to 7x keeps the image at 
8MB, and improves allocation performance from 25% to 
almost 60%. Again, points A, B, and C show the plateaus 
where we get the best allocation improvement for the 
128-, 256-, and 512-byte instances. I mage growth may be 
free, but allowing it means managing a larger OldSpace, 
and this can ultimately impact performance. 

For both free-growth and restricted-growth situations, 
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the ending memory-allocation rate is roughly the same, 
once we reach seven times the default Survi vorSpace size. 
The image in both cases stabilizes at a dynamic footprint 
of about 8M B. A larger SurvivorSpace improves memory 
allocation throughput and reduces image growth. More is 
better—a "wi n/wi n" situation. 

In many cases, changing the size of SurvivorSpace 
means tenuring problems can be traded for slightly 

AIarger Survi vorSpace i mproves 
memory allocation throughput and 
reduces image growth. 

more time spent on NewSpace GC work. Many of the 
thresholds decided by ParcPIace-Digitalk for VW date 
from 1990, and CPU performance, have greatly 
increased since then. One can easily increase the 
amount of memory that the scavenger needs to exam¬ 
ine, without noticing any effects on response time; and 
as our examples show, you can improve your applica¬ 
tion’s performance by 200%! 

Of course, yourapplication may not have a small work¬ 
ing set. Even so, some tests are worth doing. Consider 
altering your SurvivorSpace allocation by a factor of lOx, 
and observe the final dynamic memory footprint and 
time needed to complete a certai n task. 

This article addresses only NewSpace GC work. In an 
upcoming issue, I will discuss how memory is allocated, 
and what happens if you don't have sufficient memory on 
hand when you ask for another M B (or two) of that elusive 
resource. 

SUPPORTING CODE 

From Visual Works(R), Release 2.5 on September 26,1995: 

Object subclass: #EarlyTenureTest 

instanceVariableNames: 'holdTooLong counter 
allocationSize trackAllocations logStream canStop 
waitSync' 

classVariableNames:" 
pool Dictionaries: " 
category: 'J MM-Memory-Paper'l 
EarlyTenureTest comment: 

©1996John M. McIntosh, All Rights Reserved. 
johnmci@ibm.net. 

An object that creates the EarlyTenure problem so we 
can examine NewSpace behavior: 


InstanceVariables: 


holdTooLong <Array>holder for stri ngs of 

size allocationSize 


<1 nteger>iterates over the array to place 
elements 

allocationSize <lnteger> holds current allocation size 
for Strings 

trackAllocations <lnteger> hold total number of alloca 
tions 

logStream <Stream> log of information about 
test cycle 

canStop <Boolean>true when I can stop 

waitSync <Semaphore> used to sync workand 

result log 

Note: to test this you must invoke the sizesAtStartup:, then 
quit and save your image After restart of the image, 
invoke thresholds: to reset the NewSpace memory thresh¬ 
old. You may need to adjust sizesAtStartup: if your installa¬ 
tion has already altered some of the other memory space 
sizes. 

ObjectMemory sizesAtStartup: #(1.0 7.0 1.0 1.0 1.0 1.0). 
ObjectMemory thresholds: #(0.96 0.95 0.90)'! 

!EarlyTenureTest methodsFor: 'actions'! 

createElement 

self holdTooLong at: self incrementCounter 
put: (String new: self allocationSize)! 

incrementCounter 

self trackAllocations: self trackAllocations +1. 

''counter : = counter >= self defaultCounter 
ifTrue: [1] 

ifFalse: [counter +1]! 

runForThisManySeconds: aNumber 

"Fork the delay timer, fork the work, when done return 
the logStream contents" 

self forkTimer: aNumber. 
self forkAllocation. 
self waitSync wait. 

"'self logStream contents! 

writeSize 

"Print the time, memory footprint, scavenges and total 
allocations for our records" 

self logStream nextPutAII: Time now printstring; 
space; 

nextPutAII: ObjectMemory 
dynamicallyAllocatedFootprint printstring; 
space; 

nextPutAII: ObjectMemory current numScavenges 
printstring; 
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space; 

nextPutAII: trackAllocations printstring; 
cr! ! 

!EarlyTenureTest methodsFor: 'defaults'! 

defaultCounter 

"500! 

defaultPriority 

"Processor userBackgroundPriority! 
defaultSize 

"Do not change over 1000 bytes" 

"512! ! 

!EarlyTenureTest methodsFor: 'accessing'! 

allocationSize 

"allocationSize isNil 

ifTrue: [allocationSize : = self defaultSize] 
ifFalse: [allocationSize]! 

allocationSize: aNumber 
allocationSize : = aNumber! 

canStop 

"canStop! 


initialize 

holdTooLong : = Array new: self defaultCounter. 
counter : = 0. 

logStream : = WriteStream on: (String new: 1024) 
canStop := false. 
trackAllocations := 0. 
waitSync : = Semaphore new! ! 

!EarlyTenureTest methodsFor: 'forks'! 

forkAllocation 

[self writeSize. 

[self canStop] whileFalse: [self createElement], 

self writeSize. 

self waitSync signal] 

forkAt: self defaultPriority! 

forkTimer: aNumber 

[(Delay forSeconds: aNumber) wait, 
self canStop: true] 

forkAt: self defaultPriority +1.! ! 

ii n | 

EarlyTenureTest class 
instanceVariableNames:''! 


canStop: aFlag 
canStop : = aFlag! 

holdTooLong 

"holdTooLong! 

holdTooLong: anArray 
holdTooLong : = anArray! 

logStream 

"logStream! 

logStream: aStream 
logStream : = aStream! 

trackAllocations 

"trackAllocations! 

trackAllocations: aNumber 
trackAllocations : = aNumber! 

waitSync 

"waitSync! 

waitSync: aSync 
waitSync : = aSync! ! 

!EarlyTenureTest methodsFor: 'initialize-release'! 


!EarlyTenureTest class methodsFor: 'instance creation'! 
new 

"super new initialize! ! 

!EarlyTenureTest class methodsFor: 'Example'! 
example 

"self new allocationSize: 128; runForThisManySeconds: 
15.! ! a 
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